전세계 수만 명의 개발자가 수십 년 동안 서비스를 운영하고 있는 구글의 엔지니어는 어떤 모습일지 영감을 얻기 위해 “구글 엔지니어는 이렇게 일한다.” 책을 구매했다. 이 포스팅은 이 책을 요약한 글이다.
Part1 전제
Chapter 1. 소프트웨어 엔지니어링이란?
- 소프트웨어 엔지니어는 언젠간 변경될 가능성에 신경써야 한다.
- 프로그래밍 작업과 엔지니어링 작업(개발 + 수정 + 유지보수)의 차이는 시간이라는 요소가 더해지면서 입체적으로 바뀐다는 점이다.
- 십 년 이상 살아남는 시스템은 거의 모든 의존성이 처음과 달라질 것이다. 소프트웨어 엔지니어링과 프로그래밍을 가르는 핵심은 이 사실을 인식하는 데서 시작한다. 이 차이가 소프트웨어의 지속 가능성의 핵심이다.
- 초기에 소프트웨어 엔지니어링을 “여러 버전의 프로그램을 여러 사람이 참여해 개발하는 것”이라고 정의했다. 협업 자체로 새로운 문제를 유발하지만, 한 명이 개발하는 것보다 가치 있는 시스템을 만들어낼 잠재력 또한 지닌다.
- ‘조직이 성장하고 프로젝트가 확장될수록 소프트웨어 생산 효율도 높아지는가?’ 규모에 따른 소통, 인력 충원 문제는 소프트웨어 엔지니어링 초창기부터 논의되어 온 주제다.
- 주기적으로 여러 선택지 사이의 트레이드오프를 평가 해야 한다. 때로는 불완전한 지표에 기대어 결과에 커다란 영향을 주는 선택을 해야 한다.
- 지속 가능성을 잃지 않으면서 조직, 제품, 개발 워크플로우의 규모를 확장하는 비용을 관리해야 한다. 이런 사실을 주지하고 트레이드오프를 평가해 합리적인 결정을 내려야 한다.
- 때로는 유지보수에 도움되는 변경, 확장성이 떨어지는 정책을 받아들여야 할 때도 있다. 이런 결정은 훗날 다시 검토해야 할 수 있음을 잊지 말아야 하고, 이 결정 때문에 생긴 지연 비용을 정확히 계산해둬야 한다.
- 규모가 커질수록 효과도 커지는 엔지니어링 생태계의 보고서같은 책이라고 생각하라고 한다.
- 구글에서 대부분 프로젝트는 5년 이내에 업그레이드를 했다.
- 수명이 길어질수록 ‘동작한다’와 ‘유지보수 가능하다’의 차이를 더 분명하게 인지해야 한다.
- 하이럼의 법칙 : 최선의 의도, 최고의 엔지니어, 꼼꼼한 코드 리뷰가 뒷받침되더라도 완벽한 구현이라고 단정할 수 없다는 현실을 표현한 말이다. 이미 사용자가 API를 사용하고 있다면 가장 무해할 듯한 변경도 일부 사용자의 소프트웨어를 망가뜨릴 수 있다. 따라서 변경이 얼마나 유용할 지 조사할 때는 이런 충돌 조사를 하는 비용도 고려해야 한다.
- ‘기발한’이 칭찬으로 느껴지면 프로그래밍이라 하고, 질책으로 느껴진다면 소프트웨어 엔지니어링이라고 한다.
- 코드베이스 자체도 확장 가능해야 한다. 빌드 시간, 레포지토리에서 새로 프로젝트를 내려받는 시간 같은 지표는 적극적으로 관리하지 않으면 천천히 악화된다. 마치 ‘끓는 물 속의 개구리’처럼 위험 순간까지 눈치채지 못할 수 있다. 따라서 이런 문제는 조직 차원에서 챙기며 확장 가능성에 신경 써야 안정되게 관리할 수 있다.
- 마이그레이션을 담당하는 전문 그룹을 운영하는 것이 각자에게 부담시키는 방식보다 확장성이 좋았다.
- 지식을 공유하는 것이 조직 성장에 기여하는 바가 크다는 사실을 알았다. 한 명만 질문에 기꺼이 대답해 줄 엔지니어가 있다면 100명이 있는 조직일 때 더 나은 코드를 작성하는 100명의 엔지니어가 탄생한다.
- 인프라(조직 내 사용하는 모든 자원)는 더 자주 변경할수록 변경하기가 오히려 쉬워진다. 코드가 더 견고해지고, 다음 업그레이드를 하기도 더 쉬워진다. 무엇을 업그레이드하든 첫 번째 업그레이드 때 코드베이스 수정량이 가장 많을 것이다. 이런 경험을 통해 전문성, 안정성, 코드베이스의 순응(업그레이드를 겪지 않은 코드가 더 적다), 익숙함(자동화 노력), 정책(CI같은 유용한 시스템 구축)을 얻을 수 있었다.
이전 회사와 지금 회사에서 겪은 2번의 큰 경험으로 얻었던 교훈을 2006년 구글에서는 이미 가지고 있었다.
- 원점 회귀 : 결함 수정 비용은 왼쪽일수록 낮다. 구글에서는 가능한 많은 버그를 왼쪽에서 잡기 위해 다층 방어 전략을 구축하기 위해 노력한다.
- 개념잡기 → 설계 → 구현 → 리뷰 → 테스트 → 커밋 → 카나리 → 배포
- 비용을 평가할 때 조직의 건설성도 포함되어야 한다. 엔지니어들이 스스로 가치를 느끼고 생산적인 일을 하고 있다고 생각하는지가 포함된다. 행복을 느끼고, 일에 집중하고 참여할 수 있게 해주면 10~20% 생산성 향상은 우습게 만들어 낸다.